The Atari Compendium/The Atari Compendium (Toad Computers) (1994).iso/files/umich/utils/ctv201.arc/CT.DOC

Text File | 1988-03-10 | 7KB | 199 lines

Mar  4 01:18 1988  ct.doc Page 1


    You may have noticed that when you copy files with the Desktop (by
dragging icons), the new files created by the copy have a timestamp equal to
the current date and time, rather than the timestamp from the source file.

    For many situations, this is not a problem.  However, it is often
useful to maintain this timestamp when copying.  Since many command-line
copying programs (typically named 'cp' after the Unix command) for the ST
are also plagued with this problem (the ones supplied with "Gulam" and
Beckemeyer's Micro/MT C-Shell being exceptions), I wrote my own, and
called it CT, for 'copy with timestamp'.

    It wasn't until after I wrote CT that I discovered that Gulam and the
MT Csh had solved my problem.  So why bother continuing to update and improve
CT, you ask?  Mainly because of the additional capabilities that I've added
since the original version, namely:

    - now copies whole directory trees with the '-r' option.
    - allows selective backup of files with the '-b' option.  (e.g.: you're
      working on a ramdisk, and saved all your files to floppy 20 minutes
      ago.  Before you run your test program, you want to save all the
      files have changed since you last saved them to floppy.
      "ct -b * a:\" will do this.)
    - can request user verification if the destination file exists
****    - accepts wildcard file specifications, so that CT may be called up
      from the Desktop.  (Or from the Megamax graphical shell, or from
      within Flash, for instance).  (** See description of wildcards,
      below).
    - also, if called from the Desktop, waits for a keypress before
      exiting.

    Now, Gulam does have a '-r' option; however it doesn't seem to copy the
actual directory structure, but only the files themselves that are contained
in the directories.  With CT, if you specify
    ct -r a:\{bin,lib,work} c:\
then the 3 directories themselves, as well as their contents, will end up on
c:\ (just like it works on the desktop when you drag folders).

    GEMDOS BUG 'FIXED': You may also have noticed (if you work with
floppies a lot from command shells) the following problem: you are working
from a ramdisk directory, and you want to copy a file from a floppy onto the
ramdisk.  You remove the floppy that is in the drive, and insert a new floppy.
Then you type, "cp a:\folder\file.nam c:\" or some such thing, and the copy
fails, with "can't open a:\folder\file.nam".  If you then type "ls a:\" and
repeat the copy command, it will work.  This problem is fixed in CT.  GEMDOS
for some reason won't access files in subdirectories when a disk is changed,
_until_ it has a look at the root directory on the new floppy.  I basically
force it to do this if I can't open the file.

    CT is also fairly robust:
    - when expanding wildcards, CT can handle up to 2000 files in total.
      When copying directories, CT can handle up to 2000 files rooted in
      one directory.  This limit may easily be increased by modifying
      a #define in the source.
    - will allocate a very large buffer (I have it #define'd to try for
      500K).  This really helps when copying from a: to b: with one
      drive (although be warned: there are still a couple of swaps per







Mar  4 01:18 1988  ct.doc Page 2


      file).
    - if you are working under the MT Csh and you want to use CT in the
      background, then you can specify the '-m' option, to restrict CT
      from hogging all available memory.
    - when performing a recursive directory copy, CT checks for stack
      overflow.
    - if a file is not successfully copied, CT deletes the destination
      file.

Wildcards:
==========
*    - match with any string of characters.
?    - match with any single character.
[]    - match any one character within the brackets.  Ranges of characters
      may be specified as follows: [a-zA-z] meaning any lower or upper
      case alphabetic character.
{}    - match any of the specified groups of characters, e.g.
      {word1,word2,word3} will match with 'word1', 'word2', and 'word3'.

    Some examples:
    a:\{bin,lib,include}\*.c
        - matches with all '.c' files in a:\bin, a:\lib, and
          a:\include
    *
        - matches with all filenames, with or without extensions.
    c:\work\*.[ch]
        - matches with all '.c' and '.h' files in c:\work
    [d-q]*
        - matches with all files beginning with the letters 'd'
          through 'q'.

Interesting tidbits:
====================
(more than you care to know, probably, but hey, this is my moment on the
soapbox so let me enjoy it...)

    - In testing CT, I created a directory tree containing around 2,000
      files of zero length, strewn among several directories.  CT handles
      this fine, thank you, but GEMDOS just died disgracefully when I
      tried to delete these folders.  Not even a warm boot would
      resuscitate the ramdisk!

    - An easy (but not flawless) way to determine if a program has been
      called from the Desktop is simply to check if argv[0] is an empty
      string.  Most ST shells (msh, Gulam, MT Csh) will set argv[0] equal
      to the program name, i.e., "ct".  However, if a user is, er, 'using'
      a command shell that doesn't follow this standard practice, CT will
      assume that it is being called from the desktop, and will wait for a
      keypress before exiting.

    - If you go through the source code, you can't miss the inelegant
      method I use to allocate as large a buffer as possible.  It's very
      evident that I'm not using the standard Malloc(-1L) method.  Why?
      Apparently (from all I could tell) you simply cannot mix Malloc()
      and MWC's malloc() routines in the same program.  As soon as Malloc()
      is called, malloc() will refuse to allocate any memory.  Since







Mar  4 01:18 1988  ct.doc Page 3


      I doubt that Malloc() will perform 2000 allocations (I think that
      the fixed limit is well below that), I'm forced to use malloc().

    - Cconws( NULL ) seems to print one backquote ("`").

    - When run from the desktop as a .ttp program, the first tab printed
      doesn't seem to behave itself.  Just try running ct.ttp with no
      params, and you'll see what I mean.  (Although I have some very
      old ROMS, so it your mileage may vary).

    - Fread() doesn't seem to return an error code.  Even if I get the
      "Data on the disk in drive A may be damaged..." alert box, I don't
      get a negative return code from Fread().



    EMail suggestions or bug reports (not that there _are_ any :o) ) to:

    Usenet: [e-mail] (until May 1988)
        or: ...{ihnp4,allegra,decvax,utzoo,utcsri}!watmath!lily!jafischer
    Compuserve: 76626,210

    NOTE: CT is in the public domain.

    DISCLAIMER: (just to be safe) I shall not be held liable for any
    damages incurred through use or misuse of CT.  There.


                - Jonathan Fischer.